Mobile broadband radio networks typically employ a state machine in the RAN and the UE to support radio states with different throughput, i.e., data bitrate. In Universal Mobile Telecommunications System (UMTS), these states are referred to as Radio Resource Control (RRC) states. A higher radio state is used to provide a high throughput channel to the UE, but staying in that state also consumes resources of the RAN, such as associated control signaling, as well as consumes battery power of the UE. Therefore, it can be more efficient to transmit a given amount of data at a high, or highest, available bitrate of a radio link between the UE and the RAN, and then switch down to a lower radio state during an idle period to conserve network resources and battery life.
Due to the delay and resource cost, such as associated control signaling, of switching radio states, switching to a lower radio state may make sense when the idle period is sufficiently long so that the resources conserved by switching to the lower radio state are sufficiently greater than the resources expended to switch to the lower radio state and then back to the higher radio state. Typically, downswitching of radio state is triggered by detecting an idle period of data traffic using an inactivity timer. Other mechanisms can however also be used.
In a 3rd Generation Partnership Project (3GPP) Wideband Code Division Multiple Access (WCDMA) network, the high radio state corresponds to Cell_DCH/HSPA. In a Long Term Evolution (LTE) network, the high radio state corresponds to the Active substate of Connected Mode.
Decisions for when and how to initiate downswitching can be based on consideration of one or more of the following properties:                Providing good end-user experience, including quick start-up for playout of a media stream to a user, minimizing re-buffering events, and/or maximizing available bitrate,        Increasing battery efficiency by not staying longer than needed in a high radio state,        Improving radio resource efficiency by reducing resource utilization over the duration of a data streaming session to a UE by minimizing the time spent in a high radio state,        Improving data volume efficiency by avoiding downloading of data bytes that are never consumed (e.g., played) by the UE (unused data bytes are charged to the end-user's data plan and unnecessarily consume system communication resources), and        Reducing signaling load by avoiding frequent switching between radio states.        
It has been proposed to deliver video with big chunks of data at high speed, and then create long idle gaps allowing a downswitch of radio state.
Progressive video streaming is one known approach for streaming video from video servers. A video player, e.g., a functional module on a UE, may display an indication of the current play location within the video, and may further display an indication the present buffering state. FIG. 1 illustrates example information that is displayable on a display device of a UE while a video stream is being played, both with and without controlled pacing of the video stream. A certain amount of data must be received for the video player to continue to play the video stream, otherwise the video player “freezes” and waits until a playback buffer is sufficiently filled with more video data. The end-user experience during playback may be improved by fetching the entire video file as quickly as possible so that the playback buffer is full. However, after fetching the entire video file, the end-user may not watch the entire video or may seek forward and skip certain parts of the video, which results in non-viewed streamed video data.
FIG. 1 illustrates an example graph 102 of the bitrate (“Data rate” in FIG. 1) at which video is streamed from a streaming server to a UE for display in a display area 100 while pacing is not utilized. Streaming video that is ultimately not played to a user unnecessarily consumes network resources, which is discouraged by operators. For example, in the displayed area 100, if the user stops viewing the video after watching 25 seconds, the remaining 3 minutes and 55 seconds of buffered video, indicated by 104, would become a wasted portion of streamed video data.
One approach to improving efficiency is to pace, or throttle, a video stream so that the video player has just enough data in its playback buffer to enable the video player to continue playing without pauses (freezing). The streaming server can operate to pace the video stream from the streaming server to a video player on the UE consuming the video stream, so as to provide the streaming video at a bitrate that approximates the rate at the video data is consumed by the video player and independently of the available communication bitrate to the UE. Accordingly, although a communication pathway to the UE would support a higher bitrate, the streaming server paces the video stream at a bitrate that is regulated based on providing just enough data to enable playback of the video without pauses.
FIG. 1 further illustrates an example graph 112 of the bitrate at which video is streamed from a streaming server to a UE for display in a display area 110 while pacing is utilized. While using pacing, the video player is provided with just enough data in its playback buffer to enable the video player to continue playing without pauses (freezing). For example, the playback buffer can be filled at the playback rate so that the amount of buffered video, indicated by 114, is reduced or minimized.
A pre-requisite for the RAN to deliver the video stream with high radio efficiency to a streaming client, e.g., a video player of the UE, is for the streaming server to deliver the video stream with a bitrate that exceeds the inherent media bitrate by a factor of x. The factor x is a positive real number that is preferably larger than 1 and, more preferably substantially larger than 1. Increasing values of the factor x enables the UE to sleep in-between retrieving chunks of data from the streaming server, i.e., to switch to a less resource consuming radio state. However, the available bitrate to the UE is constrained by the radio interface. Since the video bitrate is typically smaller than the radio interface communication bitrate, the UE, or radio transceiver modem therein, can transition to a “sleep” state between times of high-speed data reception.
In some scenarios, for various reasons, the factor x is close to 1 or at least far below a value where the UE would be allowed to sleep any substantial time between consecutive fetches of the streaming video. The reason for this can be at least twofold:                Some policy shaping may be applied by the streaming server to constrain the video stream bitrate at a defined factor x, and/or        Downstream transport limitations constrain the video stream to a lower bitrate.        